1. Field of the Invention
The invention relates to encryption and more particularly to the renegotiation of keys used for encryption.
2. Description of the Related Art
Individuals and businesses alike use computers to transmit and receive a variety of data. A reasonable proportion of such data is likely to be sensitive and thus ensuring data privacy is important.
One popular way of achieving data privacy is through the use of an encryption algorithm. Such algorithms are typically key-based and are either classed as symmetric or asymmetric.
Symmetric encryption algorithms make use of a secret key which is known only to the sender and the receiver of the data in question. The same secret key is used to encrypt the data at the sender as is used to decrypt the data when it is received by the receiver.
Asymmetric encryption algorithms on the other hand employ both a public key and secret key (secret key). The public key can be known to anybody whilst the secret key in known only to a limited number of entities. One key is used to encrypt the data, whilst the other key permits decryption of the data.
Secure Sockets Layer (SSL) is a protocol for achieving secure data transmission over the Internet. SSL employs both asymmetric and symmetric encryption techniques.
A pair of asymmetric keys is used in an initial authentication handshake between two parties (e.g. Alice and Bob). In the following example, Alice wishes to authenticate Bob (of course Bob may also want to authenticate Alice—this is advisable). Bob has a public-secret key pair. Bob's public key is disclosed to Alice. Alice transmits a message to Bob which Bob then encrypts with his secret key and returns to Alice. Alice decrypts the message from Bob using the public key that Bob disclosed to her earlier. If the decrypted message matches the message that Alice originally sent to Bob, then Alice can assume that Bob is who he says he is. SSL however also uses digital signatures to prevent a third party from obtaining Alice's original message and impersonating Alice. SSL also makes use of certificates. A certificate is used to prove that a public key really does come from, for example, Bob.
Having authenticated Bob, Alice is now ready to exchange data with Bob. Before data exchange can however take place, Alice and Bob must agree upon a symmetric (secret) key. The data to be exchanged is first encrypted with this secret key. Since both parties have agreed upon the secret key, Alice can encrypt her data using the key whilst Bob can decrypt data received from Alice.
It will be appreciated that if the secret key is discovered by an unauthorised third-party, it can be used to decrypt data and to encrypt spoof messages/alter data.
It is for this reason that it is preferable to periodically renegotiate the SSL secret key used by Alice (client) and Bob (server) to exchange data. The renegotiation of the secret key involves performing a CPU intensive handshake on both the client and server. This is especially processor intensive when each renegotiation involves a full asymmetric authentication followed by the negotiation of a symmetric secret key.
Current Solutions
Current secret key renegotiation implementations generally use one of two methods:
(i) timed reset in which a renegotiation is initiated by the SSL client every x minutes (e.g. a web browser may initiate a key renegotiation every 2 minutes); or
(ii) initiation after a certain threshold of bytes has flowed.
These solutions do not however work efficiently in a messaging environment since in such an environment a communications link typically fluctuates between idle and busy. The solutions mentioned above are especially inefficient where a communications link is particularly idle or busy at varying times of day (as is likely in a messaging environment).
Problems with Current Solutions
(i) Timed Renegotiation—Idle Communications Link
There could be an unnecessary number of full authentications and renegotiations when no data (messages) has been sent over the communications link for a prolonged period of time. In other words, a client may needlessly often authenticate a server with which it wants to communicate and then renegotiate a secret key with that server. Thus performance is degraded unnecessarily.
(ii) Byte Threshold Implementation—Idle Communications Link
This solution increases the period of time in which a secret key is valid on an idle link and gives a hacker more time to attack the secret key and send ‘spoof’ messages without detection.
(iii) Timed Negotiation—Busy Communications Link
A busy communications link will flow a large amount of data encrypted with the same secret key. Whilst the hacker is unlikely to be able to break the key in the sort of times generally used for timed renegotiation, the problem however is that he will be able to record the encrypted data and then analyse it at his leisure. This is easier for him if large amounts of the data are encrypted with the same secret key and thus the security of a large amount of data may be compromised using this solution when the communications link is busy.
(iv) Byte Threshold Implementation—Busy Communications Link
The amount of data encrypted with the same secret key on a busy communications link will be minimised. Thus this solution minimises the amount of data encrypted with a single secret key. However this solution is not good, when the link is predominantly idle (see above).
Thus encryption in an environment that fluctuates between being busy and being idle has thus far been problematic.